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REMARKS 

The drawing has been objected to. Both the specification and the drawing are 
amended to make the application clearer and, as amended, it is believed that absolutely 
no ambiguity exists in the drawings, thereby overcoming the objection. 

Claims 1-27 were rejected under 35 USC 1 12, first paragraph because, according 
to the Examiner, the limitation 'tuple" is not found in the specification, and the disclosure 
"does not appear to lend support for the limitation 'storing a tuple in an index at a 
position corresponding to at least a portion of the first cyclical redundancy check value'." 
The Examiner, in fact, asserts that "The limitation is not logically possible ...." 
Respectfully, applicant disagrees. 

First, the word tuple is well known in the database art. In www.webopedia.com, a 
site that offers definitions in various arts, the term ct tuple" is defined as "In relational 
database systems, a record " (emphasis supplied). Short, and to the point. Rephrased, a 
tuple is a record in a relational database sense, which typically is a multi-field object (to 
distinguish it from other definitions of the word "record." 

Thus, the terms "record" and "tuple" are synonymous and the database arts, and 
the specification is amended herein to make is absolutely clear that the information stored 
in the index cluster's entries are records, or tuples. For example, the specification now 
states: 

Each index table cluster 103j contains an array of entries. Fig. 1 
illustrates clusters with four entries in which records, or tuples, can be 
stored, as illustrated by tuples, 105a - 105d of cluster 103i, but the 
number of entries may be varied to optimize the performance of the 
index table 101, as will be explained in detail below. 

Reviewing claim 1, and in particular the step of storing a tuple in the index table, the 

Examiner's attention is respectfully directed to the text that starts at page 6, line 25, and 

subsequent paragraphs. The page 6, lines 25 paragraph discloses what the specification 

calls "a hybrid method" where a composite 4-byte hash value is obtained from a data 

record and is divided into two two-byte values, or two distinct two-byte hash values are 

obtained from the data record. One of the two-byte values is used for indirect 

addressing, and the other of the two-byte values is used in the linear search. The former 

is the source of the plurality of index clusters that Fig. 1 depicts and the specification w 

describes, and the latter relates to the plurality of entries that are allocated to each index 
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cluster, into which tuples may be inserted. It is noted that the tuple inserted into an index 
cluster's entry is not the data record that the database stores; it is just the two-field 
information that allows one to access the data record. 

Turning attention to the language of the claim 1 clause that the Examiner appears 
to have a problem with, it specifies the step of "storing a tuple in an index." This 
corresponds to the storing of the two-byte CRC-16 field and the four-byte record offset 
field. See the paragraph starting at line 25 of page 7. 

The clause further specifies that the storing is "at a position corresponding to at 
least a portion of the first cyclical redundancy check value." This, of course, corresponds 
to the selection of the cluster into which the tuple is inserted based on the first CRC 
value. See line 1 of the paragraph beginning at line 1 of page 7. 

The clause still further specifies that the tuple contains '"the record address and at 
least a portion of a second cyclical redundancy check value determined for the key." 
This corresponds to the second field of the tuple, and the first field of the tuple, 
respectively, which, as described in the specification, is inserted in an index cluster entry 
such as entry 105a. 

It is noted that no logical impossibility exists, contrary to the Examiner's view. 

Based on the above, it is respectfully submitted that claim 1 is in fully supported 
by the specification and, therefore, in compliance with 35 USC 112, first paragraph. 
Since the Examiner has not commented about any other claim relative to 35 USC 112, 
first paragraph, it is assumed that the rejection of claims 2-27 was based on the fact that 
these claims depend on claim 1. Therefore, it is respectfully submitted that the rejection 
of claims 1-27 under 35 USC 112, first paragraph is overcome. 

Claims 1-27 were rejected under 35 USC 1 12, second paragraph, as being 
indefinite because, according to the Examiner, the phrase "storing a tuple in an index at a 
position corresponding to at least a portion of the first cyclical redundancy check value" 
is unclear "as to how an index can store a tuple." Respectfully, applicant traverses. 

If the Examiner means "how an index can store" in the sense that the Examiner 
believes that the acting element is the index, then applicant respectfully submits that the 
step of storing is not taken by the index, and that nothing in the subject clause actually 
suggests that the step of storing is taken by the index. If, as is more likely, the Examiner 
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questions whether a tuple can be stored in an index, the answer is clearly in the 
affirmative. In an abstract sense, a multi-field record can be stored in a computer file, 
and it is well established in the art that a multi-field record can be called a cc tuple," (see 
the remarks above). Also, a file can be called an index. Therefore, even in the abstract 
there is no lack of clarity, there is no ambiguity, and there is no violation of the 35 USC 
1 12, second paragraph requirements. With the hindsight of applicant's teachings in the 
specification, where the index that is shown in Fig. 1 has entries into which two-field 
records or tuples can be stored, the is no question as to the clarity of the phrase "storing a 
tuple in an index at a position corresponding to at least a portion of the first cyclical 
redundancy check value." Nevertheless, for sake of clarity, the following dissects the 
phrase in terms of the teachings found in applicant's specification. 



storing a tuple 


storing information that constitutes a multi- 
field record 


in an index 


in an entry of the index depicted in Fig. 1 , 
for example in the entry designated 105a 


at a position 


in a particular cluster of the index, where 
each cluster of the index is at a particular 
position in the index 


corresponding to at least a portion of the 
first cyclical redundancy check value 


which cluster is selected based on - or 
addressed by - a two-byte CRC value. 



Based on the above, applicants believe that claim 1 is in full compliance with 35 USC 
112, second paragraph, thereby overcoming the rejection. Since the Examiner has 
offered no comments relative to the rejection of claims 2-27 in connection with 35 USC 
1 12, second paragraph, it is assumed that the rejection was based on the dependence of 
these claims on claim 1. Since the above remarks overcome the rejection of claim 1 
under 35 USC 1 12, second paragraph, it is respectfully submitted that the rejection of 
claims 2-27 is also overcome. 
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In light of the above amendments and remarks, the Examiner's approval of the 
drawing amendment is respectfully requested, as well as reconsideration and allowance 
of the subject claims. 

Respectfully, 



Dated: 




Phone (973) 467-2025 
Fax (973)467-6589 
email brendzel@home.com 



i 



8 



AT&T DOCKET NO. 1999-0043 
Ser. No. 09/707.462 ' _ 
Replacement Sheet 



5/5 



FIG. 4 


• 




403 
S 


405 


407 
S 


409 
\ 


<SP 








411 
S 


413 

s 


415 


417 
S 






CP 


^> 


419 


421 


423 


425 


6P 




CD 1 




427 
S 


429 


431 

\~ 


433 






@> 





STORAGE Dl: 



401 



OOCKET NO. 1999-0043 



1/5 

FIG. 1 
Jfll 



109 



CRC-16 


RECORD OFFSET 


CRC-16 . 


RECORD OFFSET 


0 


MAXVALUE 


0 


NEXT. JQFFSET 




{03,, 



l oft 



CRC-16 



10^<» CRC-16 



CRC-16 



RECORD OFFSET 



RECORD OFFSET 



RECORD OFFSET 



NEXT OFFSET 




(REPEATS) 



CRC-16 


RECORD OFFSET 


0 


RECORD OFFSET 


0 


RECORD OFFSET 


0 


NEXT OFFSET 



109 



OVERFLOW, 



I 03, 



CRC-16 


RECORD OFFSET 


CRC-16 


RECORD OFFSET 


0 


MAXVALUE 


0 


NEXT OFFSET 




1 



1A 



